home *** CD-ROM | disk | FTP | other *** search
- From ptb@uk.ac.cambridge.engineering Sat May 15 21:48:56 1993
- Received: from uk.ac.oxford by prg.oxford.ac.uk
- id AA14271; Sat, 15 May 93 15:59:50 +0100
- Received: from gray.computing-service-internal.cambridge.ac.uk
- by oxmail.ox.ac.uk with SMTP (PP) id <04391-0@oxmail.ox.ac.uk>;
- Sat, 15 May 1993 15:50:27 +0100
- Received: from xrly.eng.cam.ac.uk by ppsw1.cam.ac.uk
- with SMTP-CAM (PP-6.0) as ppsw.cam.ac.uk
- id <26432-0@ppsw1.cam.ac.uk>; Sat, 15 May 1993 15:51:06 +0100
- From: Peter "T." Breuer <ptb@uk.ac.cambridge.engineering>
- Message-Id: <7128.9305151450@club.eng.cam.ac.uk>
- Subject: the foo.bar C expression for precc
- Mailer: Elm [revision: 70.30]
- Status: OR
-
-
- There is an omission in precc 2.23-2.31 that causes it not to recognise
- C expressions of the form `foo.bar' as valid. `foo->bar' is handled OK,
- and so therefore is `(&foo)->bar', which is one work-around.
-
- # define bar(foo) foo.bar
-
- is another. C expressions can occur in precc definitions as the
- parameters of productions and non-terminals, and in logical tests, and
- literal token matches.
-
- I never intended to make precc perfect at C expressions - one would need
- a macro interpreter to do that - but this could be annoying, so I'll
- issue the following patch for those who are really very annoyed.
-
- I judged it crazy to try and match the C infix operators too precisely,
- so precc accepts as an infix any multi-symbol combination from the set
- <>=!|&%/*-+ and as you can see, I forgot to include dot. You could mend
- this very easily if I gave you the precc specification in precc-code,
- but you don't have that (I may release it with 2.40).
-
- As it is, you will have to mend the generated code. The simplest
- revision I can think of is to add dot into the <>=!|&%/*-+ list, by
- changing the definition of the binopone() parser. Let's leave aside the
- question of why I used a parser instead of a lexical-level function of
- some kind. Maybe there aren't that many C expressions in a precc script,
- and this way is just easy to maintain.
-
- This is in the contiguous chain of parsers in the preccx.c script which
- ends with the STATUS binopone() definition. The numbering may be
- slightly different depending on whether you have 2.23, 2.30 or 2.31, so
- look for the RIGHTANGLEBRACKET or binopone in the code. This is from
- the (minor) revision 2.31, which is basically the same as 2.30.
-
- ************* begin new code ***************************************
- static STATUS hid329(){
- return(p_exactly0(RIGHTANGLEBRACKET(1)));
- }
- static STATUS hid329a(){
- return(p_exactly0('.'));
- }
- static STATUS hid329b(){
- PARSER hid329, hid329a;
- return(p_orparse0n(TOPARSER hid329,0,TOPARSER hid329a,0));
- }
- static STATUS hid330(){
- PARSER hid328, hid329b;
- return(p_orparse0n(TOPARSER hid328,0,TOPARSER hid329b,0));
- }
- ************* end new code ****************************************
-
-
- ************* begin old code ***************************************
- static STATUS hid329(){
- return(p_exactly0(RIGHTANGLEBRACKET(1)));
- }
- static STATUS hid330(){
- PARSER hid328, hid329;
- return(p_orparse0n(TOPARSER hid328,0,TOPARSER hid329,0));
- }
- ************* end old code ****************************************
-
-
- As you can see, I have just added an extra alternative into the list.
- The precc definition script from which this is generated now reads
-
- @ binopone = .....
- @ | <RIGHTANGLEBRACKET(1)>
- @ | <'.'>
-
- (the hideous RIGHTANLEBRACKET macro can be got rid of in 2.40 and above
- where <'>'> is handled properly)
-
- --
- Peter
-
-